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Preface 



The IBM 7090/7004 ibjob Processor Debugging Pack- 
age provides a means of taking highly selective dumps 
of core storage areas and machine registers with a min- 
imum of programming effort. By carefully selecting the 
areas to be dumped and the time at which to dump 
them, the user can obtain valuable information for 
locating and correcting program errors. The facilities 
described in this publication pertain to Fortran iv, 
COBOL, and map program debugging. 

As a prerequisite to understanding this publication, 
the reader should be familiar with the ibjob Processor, 
as described in the ibm publication IBM 7090/7094 
IBSYS Operating System: IBJOB Processor, Form 
C28-6389, and with at least one of the programming 
languages accepted by the processor, as described in 
the IBM publications: 

IBM 7090/7094 IBSYS Operating System: Macro As- 
sembly Program (MAP) Language, Form C28-6392 

IBM 7090/7094 IBSYS Operating System: FOB- 
THAN IV Language, Form C28-6390 

IBM 7090/7094 IBSYS Operating System: COBOL 
Language, Form C28-6391 

The compile-time debugging language ( for use with 
COBOL programs ) is based on cobol, and the load-time 
debugging language ( for use with both Fortran iv and 
MAP programs ) is based on Fortran iv. The map pro- 
grammer who is totally unfamiliar with Fortran 
should be able to use all of the facilities described 
herein with limited reference to the Fortran language 
publication listed above. 

The 7090/7094 ibjob Processor Debugging Package 
requires the same minimum machine configuration as 
the 7090/7094 ibjob Processor except that a unit speci- 
fied as SYSCK2 is required for debugging output when 
the load-time debugging facility is used. 

The problem of locating errors in programs rapidly 
and efficiently is of major concern to all computer users. 
The 7090/7094 ibjob Processor Debugging Package 
meets this problem by allowing the programmer to ma- 
nipulate data, control piocessing, or dump the contents 
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of any relevant areas by inserting debug requests at 
key points in his program. To use the debugging pack- 
age, the programmer writes a debug request in the ap- 
propriate debugging language. Each request specifies 
the pOMit(s) in the program at which the specified 
action is to be taken. Any reasonable number of re- 
quests may be given for a single program. 

The debugging package provides two types of de- 
bugging. The first, compile-time debugging, is included 
with iBCBC at compilation to specify dumps at various 
points in a cobol source program. In this type, the text 
of debug requests is similar to the cobol language. The 
second type, load-time debugging, uses the capabilities 
of iBLOR to provide debugging during tiie execution of 
a FORTRAN IV or MAP program without recompilation 
or reassembly. In this type, the text of debug requests 
is written in form similar to the Fortran iv language. 

This publication describes the debugging package in 
two parts: Part i describes the compile-time facility for 
COBOL programs; Part ii describes the load-time facility 
for FORTRAN IV and map programs. These parts are in- 
dependent of each other, so that reference to one is not 
required when reading the other. The material in Part ii 
is divided into two sections, "Load-Time Debug Re- 
quests" and "Additional Load-Time Debugging Fea- 
tures." The FORTRAN IV programmer will generally use 
only the facilities described in the first section, whereas 
the MAP programmer will use the facilities described in 
both sections. 

The following conventions apply to all card formats 
given in this publication: 

1. Brackets [ ] indicate that the enclosed material 
may be omitted. 

2. Braces ( } indicate that a choice of the enclosed 
material is to be made by the user. 

3. Upper-case words, if used, must be present in the 
form indicated. 

4. Lower-case words represent generic quantities 
whose values must be supplied by the user. 
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Part I: Compile-Time Debugging for COBOL Programs 



The compile-time facility of the debugging package 
enables the cobol programmer to specify debug re- 
quests with his source-language program. The requests 
are compiled with the source program and are exe- 
cuted at object time. The text of the request is very 
similar to the procedural text of cobol. In addition, a 
special count-conditional statement is provided. Since 
procedural capabilities of the cobol compiler are avail- 
able, a, user can be highly selective in specifying what 
is to be dumped. He can manipulate and test the values 
of data items in his program and dump only pertinent 
and meaningful information, without affecting execu- 
tion of the program itself . 



Cbrnpf'/e-Tfme Debugging Packet 

All compile-time requests for a given program are 
grouped together into a debugging packet. The com- 
pile-time debugging packet is placed immediately 
following the scbend card of the associated source 
program. 

Compile-Time Debug Requests 

Each compile-time debug request is headed by the 
control card sibdbc. The sibdbc card serves two func- 
tions: it identifies individual requests, and it defines 
the point at which the request is to be executed. The 
general form of this card is 



1 
$IBDBC 



8 16-72 

[name] location 



[, FATAL] 



where the parameters are described as follows: 

name An optional user-assigned control section name, 

which permits deletion of the request at load 
time. This name must be a unique control sec- 
tion name consisting of up to six alphabetic 
and/or numeric characters, at least one of which 
must be alphabetic. 

location The COBOL section-name or paragraph-name 

(qualified, if necessary) indicating the point in 
the program at which the request is to be ex- 
ecuted. Effectively, debug request statements 
are performed as if they were physically placed 
in the source program following the section- or 
paragraph-name, but preceding the text associ- 
ated with the name. 

FATAL If this option is exercised, loading and execution 

of the object program will be prevented when- 
ever an error of level E or greater occurs within 
a debug request statement. If FATAL is not 
specified, a COBOL error of level E or less, 
when encountered in the procedural text of a 
debug request, will not prevent loading and 



execution of the object program. Instead, an 
attempt will be made to interpret the statement. 
If interpretation is impossible, the erroneous 
statement ( but not the entire request if it con- 
sists of more than one statement) will be dis- 
carded. 

The text of the debug request follows immediately 
after the sibdbc card. The text may consist of any valid 
procedural statements conforming to the requirements 
of the COBOL language and format and of the count- 
conditional statement described in the following text. 
The only restriction on these statements is that they 
may not transfer control outside of the debug request 
itself. A procedure-name in a debug request must be 
unique to the request in which it appears, to all other 
debug requests, and to the source program. Display 
statements in a debug request write on sysoui. 

A compile-time debug request is terminated by an 
end-of-file card, another sibdbc card, or a $-control 
card. 

Count-Conditional Stafnfnt 

A count-conditional statement, available for use only 
in debug requests, provides the programmer with a 
means of qualifying the time when a debugging action 
should be taken. The count-conditional statement has 
the same structure as the cobol if statement (condi- 
tional, true option, false option) and may be used in 
the same manner; i.e., it may be nested within other 
count-conditional or if statements and may have other 
count-conditional or if statements nested within it. The 
general form of the count-conditional statement is 
ONm [AND EVERY n,] [UNTIL m] statement-1 

[_]oTHERWISEf statement-2j 

where Ui, n-, and ns are positive integers. If the and 
EVERY n^ option is not specified, but the until ng option 
is specified, n2 is assumed to be one. The until option 
means up to but not including the n.<ith time. 

Some examples of the count-conditional statement 
follow; 

ON 3 DISPLAY A. 

On the third time through the count-conditional state- 
ment, A is displayed. No action is taken at any other 
time. 

ON 4 UNTIL 8 DISPLAY A. 

On the fourth time through the seventh time, A is dis- 
played. No action is taken at any other time. (This 
example implies, and has the same effect as, the state- 
ment ON 4 AND EVERY 1 UNTIL 8 DISPLAY A.) 

ON 5 AND EVERY 3 UNTIL 12 DISPLAY A. 

On the fifth, eighth, and eleventh times through the 
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count-conditional statement, A is displayed. No action 
is taken at any other time. 

ON 3 AND EVERY 2 DISPLAY A. 

A is displayed on the third, fifth, seventh, ninth, etc., 
times. On the first, second, fourth, sixth, etc., times, no 
action is taken. 

ON 2 AND EVERY 2 UNTIL 10 DISPLAY A ELSE 

DISPLAY B 

On the second, fourth, sixth, and eighth times, A is dis- 
played. B is displayed at all other times. 

A Compllm-Tinf Debugging Poclcaf 

The numbers given in the left-hand column of the 
example in Figure 1 are for purposes of reference in 
the explanations that follow; they are not part of the 
requests themselves. The numbers in the first line 

I H 12 16 



SIBOBC A 

ON I AND EVERY 3 UNTIL 6 DISPLAY 

•Z"' Z. 
(IBDBC CNTRL B OF C 

IF S UNE3UAL TO T DISPLAY 'S«' S, 

MOVE T TJ S. DISPLAY 'T-* T. 
tIBDBC D. FATAL 

IF V GREATER THAN VHAX ON I U^TIL 

10 DISPLAY 'V OUT OF RA;4GEt V«' V 

ELSE STOP RUN. 



Figure 1. Example of a Compile-Time Debugging Packet 



across indicate the card columns in which the various 
fields begin. 

In the first request, on the first, fourth, and seventh 
time that control passes through point A in the pro- 
gram, Z is displayed (in its own format) with the iden- 
tifying heading Z ==. 

In the second request, the value of T (with the iden- 
tifying heading T = ) is displayed at the point in the 
program identified as b of c. Also, if S is unequal to T, 
S is also displayed and its value is adjusted to the value 
of T. If desired, this debug request may be deleted 
during this and/or subsequent runs by using a iomit 
control card, which is described in the publication IBM 
7090/7094 IBSYS Operating System: IBJOB Processor, 
Form C28-6389. 

Execution of the third request causes both the mes- 
sage v out OF RANGE, V = and the value of V to be dis- 
played the first nine times that V is greater than vmax 
when program control passes through point D. On the 
tenth time, this request causes an exit from the program 
(i.e., ELSE STOP run). The fatal option on the sibdbc 
card heading this request prohibits loading of the 
source program if the compiler encounters an error of 
level E or greater in the text of this request. 



Part ri: Load-Time Debugging for FORTRAN IV and MAP Programs 



The load-time facility of the debugging package pro- 
vides FORTRAN IV and MAP programmers with the means 
to insert debug requests at load time to be executed 
with the object program, map object programs in- 
clude those generated by ibcbc as well as those written 
in MAP itself. Thus, the cobol programmer may, if de- 
sired, take advantage of the load-time facility and de- 
bug from an assembly listing of his program; the 
FORTOAN IV programmer may also use the load-time 
facility at the map level. 

The debugging language used with the load-time 
facility is derived from the Fortran iv language, with 
changes and additions made for debugging purposes. 
The statements available in the debugging language 
permit the programmer a high degree of flexibility in 
obtaining meaningful data in his dumps. It is possible 
to perform arithmetic operations on object time and 
debug packet values, to test and manipulate results, 
and to select the quantities to be dumped. Also, the 
programmer can reference symbols appearing in the 
source program by selecting the appropriate dictionary 
option in his source program. When more than one 
name has been given to a program area (for example, 
by the use of equivalence statements or common def- 
initions in different decks), the load-time debugging 
postprocessor chooses unpredictably from among these 
names when dumping the area. The only way this 
problem can be avoided is by not multiply-labelling 
such areas; it can be minimized by using the dump 
msg' statement to label the dump as desired. 

In the discussions that follow, the term "integer" is to 
be interpreted as follows: if it is prefixed with a leading 
zero and does not contain any invalid octal characters 
(i.e., 8 or 9), it will be considered octal. Otherwise, it 
will be considered decimal. 

Load-Time Debugging Paclcet 

All of the load-time debug requests for a particular 
job run (which may consist of any configuration of 
FORTOAN, COBOL, Or MAP sourcc and/or object decks) 
are grouped together into what is called the debugging 
packet. The packet is headed by a sibdbl card and ter- 
minated by an *dend card. These control cards are de- 
scribed in the publication IBM 7090/7094 IBSYS Oper- 
ating System: IBJOB Processor, Form 028-6389. The 
load-time debugging packet is placed at the beginning 
of the job deck, preceding the source and/or object 
decks. 

Load-Time Debug Requests 

A debug request is a set of actions to be performed at 



loci, . . . 



an indicated point in the program called the insertion 
point. Each load-time debug request is headed by the 
♦debug card, which identifies individual requests and 
specifies the insertion point(s) of the request in the 
program. 

The general form of the *debug card is: 

1 8 16-72 

•DEBUG [deckname] loci [, loc2, loc3, . . .] 

Blanks may be included in the variable field for legi- 
bihty but they may not be imbedded. The parameters 
of the *debug card are as follows: 

deckname The name of the object deck to which this de- 

bug request appHes. If this field is blank, the 
last deckname specified on the preceding ♦DE- 
BUG or *REDEF card is assumed; if a deck- 
name was not previously specified, the request 
is deleted. Library subroutines cannot be re- 
ferred to in a debug request. 

The location(s) of the executable instruction(s) 
at which this debug request is to be inserted. A 
location may be specified in any of the following 
ways: 

1. A statement number (FORTRAN only). 

2. A symbol.* Symbols used in debug requests 
may not contain parentheses," 

3. A sjmibol ± an unsigned decimal integer. 

4. =R followed by an unsigned octal integer 
for a relative location (i.e., relative to the 
load address of the deck). 

5. =A followed by an unsigned octal integer 
for an absolute location. 

6. An internal formula number of a FOR- 
TRAN statement with the suffix A (e.jr 
10A).» * 

Because of the method by which insertions are 
made in the program (i.e., the STR instruction ), 
the programmer should take care not to specify 
insertion points at instructions whose prefix 
might be modified during execution. This is pri- 
marily of concern to the MAP programmer. 
Violation of this rule may result in unpredict- 
able results and/or actions. No check is made 
for this condition. 

The debug request is executed as if it had been phys- 
ically inserted in the deck at the specified location(s). 
The debug request action occurs before the execution 
of any action indicated by the statement or instruction 
at that location. 



'These symbols must consist of one to six nonblank BCD characters At 

!rtercV.?r5r^aVtere^d': "'"'* ^^ ^"«'"^«*- ""* "-« 3*r SL^-' 



+ (plus sign) 

— (minus sign) 

• (asterisk) 

/ (slash) 

$ (doUar sign) 



( equal sign ) 
( comma ) 
( apostrophe ) 
(left parenthesis) 



) (right parenthesis) 
'Hjis resWction applies only to symbols that are explicitly given in a 
IXthe 5S?55iV*'L,^''/i^'' mjy .ppear in Ae drugging "dirtionary 
fheVSthlX'^m^lJterrei^lJtl^"^'*'" " """' "' """""'"« 

dJbug'SnTSc.iSSSS^hiSTe^n'r^Ses^/"'"*'"^ ""'>' -''^" '"^^ '"" 
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The variable field of an ♦debug card may be extended 
over more than one card by punching cards following 
the first as shown: 

1 8 16-72 

*ETC extension of variable field 

Immediately following the *debug card is the text of 
the request itself. If an invalid or erroneous action is 
specified in the text, that action is deleted. The text 
consists of procedural statements written in the For- 
tran format. At least one blank should follow each 
statement verb (e.g., DUMPbx).^ These statements are 
derived from the Fortran iv language, with additions 
and changes made for debugging purposes. The per- 
missible statements are: 

STOP statements 

PAUSE statements 

CALL statements 

RETURN statements 

Unconditional GO TO statements 

SET (arithmetic) statements 

Logical IF statements 

ON statements 

DUMP statements 

LIST statements 

NAME statements 

Comment cards having a C in column 1 are allowed. 
Library subroutines cannot be referred to in a debug 
statement. 

The operator ♦♦(exponentiation) and functions are 
not allowed, nor are references to the dummy variables 
of functions and subroutines. Subscripted variables may 
have no more than three subscripts. Fortran variables 
having more than three dimensions are treated as 
single-dimension variables by the debugging package, 
that dimension being the product of the dimensions 
specified in Fortran. The following rules apply to the 
referencing of such variables: 

1. The variable is treated as though it had occurred in the 
statement: 

DIMENSION var(d) 
instead of: 

DIMENSION var( d,. di, . . . , d.) 
where: 

n > 3 and d = di*d.*. . . •d.. 

2. In order to refer to the element: 
I var ( Si, Si, . . . , s„) ( n > 3 ) 

the reference must be written as 

var (s) 
where: 

s = s, + di (s, - 1 + d.(s,- 1 + ... + d.., (s.-l)...)) 
Thus, if we desire to refer to A (2, 3, 4, 5) and A has dimen- 
sion ( 10, 9, 8, 7 ) we compute: 

s = 2 + 10(3- 1 + 9(4 - 1 + 8(5- I))) 
or 

s = 2+ 10*2+ 10'9-3 + 10'9-8«4 = 3172 
so that the desired reference is A(3172). The reference A (I, 
J, K, L) would be written: 

A(I + 10*(J - 1 + 9*(K - 1 + 8* (L - 1)))) 
in the debugging language. 

"However, unlike FORTRAN IV, the debugging routine treati blanks in 
a itatement at tenninaton. Therefore, no bifanki may be imbedded in a 
cfaarai:ter string that is to be treated as a single symbol. 



Debugging Control Statomonl$ 

The STOP statement terminates execution. 

The PAUSE statement prints the message "debug re- 
quest pause" and then the machine halts; pushing 
START restarts processing at the next debug statement. 

The CALL statement is used in calling subroutines. It 

has the form: 

CALL SUBR 

or 
CALL SUBR ( arg,, arg,. . . . ) 

The CALL cannot induce overlay and cannot have 
non-standard returns. Machine registers are saved upon 
entry to the call and restored upon exit from the call. 
Machine registers that are initially available in the call 
diflFer from those that are saved. 

Note: A call should not be made to a subroutine 
which in turn executes another debug request. Such a 
relationship between debug requests is called "nest- 
ing." An error message will result from the attempted 
execution of the second debug request and execution 
of the entire job will terminate. 

The RETURN statement causes a return to the inter- 
rupted program; there is an implicit return at the end 
of each debug request. 

The statement go to n, where n is a decimal integer, 
is an unconditional transfer to the debugging statement 
having the corresponding integer (statement number) 
n in columns 1-5. Statement numbers used in an uncon- 
ditional GO TO statement must refer to statements within 
the debugging packet, not to statement numbers in the 
deck being debugged. 

SET (Arlthmotit) Statomont 

The SET statement provides the programmer with arith- 
metic capabilities within a debug request. The general 
form of this statement is 

SETS 
where s is any valid Fortran iv arithmetic statement 
not containing functions, the ♦♦(exponentiation) opera- 
tor, nor the logical constants .true, and .false.. Be- 
cause FORTRAN IV conventions override map notation, 
those map symbols that would be incorrectly treated in 
an arithmetic statement (e.g., 1.2) should be redefined 
prior to use. See the explanation of the ♦redef card for 
details of the redefining facility. 

LogkttI IP Stafomonf 

The debugging logical if statement is similar to that of 

FORTRAN rv, with certain additions and restrictions. The 

general form of this statement is: 

IF(t)s 
or 
IFbtbs 

where b represents one or more blanks, t is any logical 
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expression not containing function calls or the ** oper- 
ator, and s is an unconditional executable statement or 
an ON statement followed by an unconditional execut- 
able statement. The statement is executed if and only 
if it is logically true ( nonzero ) . 

The permissible logical operators (where b repre- 
sents a blank and x and y are logical expressions) are: 

bNOTbx or b .NOT. bx 

xbANDby or xb .AND. by 
xbORby or xb .OR. by 

The permissible relational operators are: 



RELATION 

bGTb or b .GT. b 

bGEb or b .GE. b 

bLTb or b .LT. b 

bLEb or b .LE. b 

bEQb or b .EQ. b 

bNEb or b .NE. b 



DEFINITION 

Greater than 

Greater than or ccinal to 

Less than 

Less than or equal to 

Equal to 

Not equal to 



bLGTb or b .LGT. b Logically greater than 

bLGEb or b .LGE. b Logically greater than or equal to 

bLLTb or b .LLT. b Logically less than 

bLLEb or b .LLE. b Logically less than or equal to 

bLEQh or b .LEQ. b Logically equal to 

bLNEb or b .LNE. b Logically not equal to 

The permissible arithmetic operators are: 
+ addition 
— subtraction 

* multiplication 

/ division 

Where parentheses are omitted, the hierarchy of 
operations is as follows: * and /; + and — ; relational 
operations; not; and; or. 

Folk) wing are some examples of the if statement: 

IF ( B EQ A*3.5 ) DUMP X, Y, Z 
IF A( I, I-J ) EQ 3.4E2*QSUM DUMP X 
IF (X .EQ. 3 .AND. Z .LT. 24) GO TO 3 
IF LOGVAR .AND. 

(ALPHA -1-6 LE BETA OR LGVARl ) RETURN 

ON Stcrtemenf 

The on statement is a count-conditional statement that 
permits the programmer to control the time when a 
debugging action is to be taken. It is similar to the 
FOR-niAN IV logical if statement and is of the general 
form 
I ON[(x)]a, [,a.][,a3]s 

where the at are any arithmetic expressions ( if they arc 
not integral, they will be truncated); x is a unique sym- 
bol, which should not be contained in the debugging 
dictionary, that represents a counter name; and s is an 
unconditional executable statement or an if statement 
followed by an unconditional executable statement. 
Additional information about the debugging diction- 
ary is provided in the publication IBM 7090/7094 
IBSYS Operating System: IBJOB Processor, Form C28- 
6389. 

The ON statement is defined as true the aith time it is 
executed and every a.sth time thereafter until a2 is ex- 



ceeded. If a- is null, the statement is true the aith time 
and every a.tth time thereafter. If a;i is omitted, it is 
assumed to be one. If both a^ and a.t are omitted, the 
statement is true only the a,th time. 

If X is specified, it creates a named counter for the 
on statement and x may be used in any computation 
or test, the same as any other variable, and may be 
named in other on statements. If the same counter is 
used by several on statements, it is incremented for 
each one of the on statements that is executed. Thus, 
the counter can be set and reset to any desired value. 
Effectively, the statement o\'(ctr) aj, iij, a.t s is the 
same as the statements 

NAME CTR/ = NEW(X) 



SET CTR = CTR + 1 

IF ( CTR GE a, AND CTR LE a. 

AND ( ( CTR - a, ) /a. ) *a3 EQ CTR - a, ) s 

All references to x are taken as refen^nces to this 
counter. Therefore, if x is duplicated by a symbol in 
the debugging dictionary, it will not be possible to 
refer to that object program symbol in a request. 

If X is not specified, an unnamed counter is created 
internally. This counter is distinct from any other 
counter. 

DUMP Statement 

The DUMP statement causes the dump of the quantities 
which are to be printed as debugging output. It is simi- 
lar in structure to the Fortran iv write statement and 
is of general form 

DUMP List 
where list is a series of items that are either direct ref- 
erences to the data to be dumped or the statement 
number(s) of list statements specifying the data to be 
dumped. The acceptable data specifications for either 
direct references or list statements are itemized under 
the discussion of the list statement. 

The DUMP statement causes information to be written 
on SYSCK2. The postprocessor edits the data on sysck2 
and writes it on sysoui. The formats supplied for the 
items of the dump statements are as follows: 

1. The symbolic reference of the item along with its 
relative and absolute locations and deck name is writ- 
ten to identify the debugging output. 

2. The value(s) of the item is written. The format, 
which is based upon the number of elements in the 
item and the mode of the item, is derived as follows: 



TYPE 

Octal 

Symbolic 

Instruction 



NO./lINE FORMAT 

4 op* xxxxxx xxxxxx 

2 ± X xxxxx X xxxxx op a,t,d* 
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TYPE 


no./line 


FORMAT 


Symbolic 
Command 
Floating- 
Point 

Fixed-Point 
Double- 
Precision 


2 

6 

6 
4 


±x xxxxx X xxxxx op(n*) a„d* 

±.xxxxxxxx±xx 

±xxxxxxxxxxxx. (leading zeros dropped) 
± .xxxxxxxxxxxxxxxxD±xx 


Complex 

Logical 

Alphameric 


3 

8 

72 char 


±.xxxxxxxx±xx ±.xxxxxxxx±xxj 
.TRUE, or .FALSE. 

XXXX...XXX 


UST Stafnfnt 





The UST statement specifies the storage areas and/or 
registers that are to be dumped; it is of the general form 
where the statement number is a standard Fortran 
statement number of up to five numeric characters 
(punched in columns 1-5) and the items denote the 
addresses of the ,quantities to be dumped. Any reason- 
able number of items may be specified; they are sepa- 
rated by commas. The permissible items are detailed in 
the following text. Except where otherwise indicated, 
the term "symbol" in the following items refers to a 
symbol that either appears in the debugging dictionary 
or is defined in a name statement. The mode of the 
data dumped is determined from the debugging dic- 
tionary or from the NAXfE statement; if this information 
is not available, the dumps will be octal except where 
the mode is specified as in item 2 in the following text. 
The permissible items are: 

1. quantity— This may be one of the following: 
symbol This causes the array, the double-precision float- 

ing-point number, die complex number, or the 
single word denoted by this symbol to be 
dumped, 
symbol This causes the array element, the double-pre- 

(subscript(s)) cision floating-point number, the complex num- 
ber, or the single word denoted by this sub- 
scripted symbol to be dumped. Any symbol may 
be singly subscripted, but only those symbols 
that have been dimensioned may have more 
than one subscript. The subscripts may be any 
arithmetic expressions. The mode of the dump 
is the same as the mode of the symbol. If 
ALPHA(6) is specified, the contents of the loca- 
tion ALPHA +5 is dumped except where 
ALPHA is double precision or complex, in 
which case ALPHA +10 and ALPHA + 11 are 
dumped, 
symbol ± n TTiis causes the single word denoted by this 
quantity to be dumped. Symbol is as defined 
in the preceding text and n is an unsigned deci- 
mal integer. The location in core storage which 
is dumped is n places removed from the symbol. 
The mode of the dump is determined from the 
referenced location and is not necessarily the 
same mode as the symbol. 
■sRn This causes the word at relative location n, 

where n is an unsigned octal integer, to be 
dumped. Only one word is dumped, even though 
it may be part of a double-precision or a com- 
plex number. 



*ap (n*) «. t. d nfm to die »nnboUc repretentaHon of a machine lan- 
Suaxe instnicdon. (n*) if z if this is a dump request point. This is pri- 
marily of interest to the MAP programmer. 



=An ' This causes the word at absolute location n, 

where n is an unsigned octal integer, to be 
dumped. Only one word is dumped, even though 
it may be part of a double-precision or a com- 
plex number. 

The MAP programmer is referred to the sections 
"Quantities Available for Use in Debug Request State- 
ment.c" and "Address Computation" for more complex 
ways of addressing quantities. 

2. (loci, loc2 [, m]) — This causes the region from 
loci through loc2 to be dumped in the format m. Loc is 
any of the quantities previously defined or a statement 
number within the source program. If m is specified, it 
overrides any other mode designations given for the 
I quantities involved. If m is not specified, the region is 
dumped in the mode(s) of the item(s) in the region. 
These modes are supplied in the debugging dictionary 
or NAME statement. The permissible values of m are: 

O Octal 

S Symbolic instruction 

C Symbolic command 

F Floating-point number 

X Fixed-point number 

D Double-precision floating-point number 

J Complex number 

L Logical 

H Alphameric 

Thus, (lOC3(6), L0C4(3,4), f) cauSCS LOC3 + 10 

through LOC4+11 to be dumped in floating-point mode 
if LOC3 is a double-precision array and loc4 is a float- 
ing-point array with dimensions of (3, 10). (e, ~ri27) 
causes the region from statement number 6 through 
relative location 1278 to be dumped in the mode(s) 
suppUed by the debugging dictionary or name state- 
ment (ahhayi,array2,x) causes all of abrayi, all in- 
tervening locations, if any, and all of arrays to be 
dumped in the fixed-point decimal mode. 

3. (data list, range)— This causes selected elements 
of arrays to be dumped. Data list may be one of the 
following: 

symbol (subscript(s)) e.g., (A(I), I « 1, 4) 

(data list, range) e.g., ((B(I, J), I = 1, 4), J « 1. 3) 

data list, data list, . . . e.g., (A(I), (C(J, I), J = 1, 9. 2), 

D(I). I = 1, 4) 

Any arithmetic expression may be used as a sub- 
script. If the expression is not integral, it will be 
truncated. 

Range is of the form 
V « ai, at [, at] 
where v is any symbol and the at are arithmetic expres- 
sions. If the same symbol appears elsewhere in the pro- 
gram or in another debug request, that use(s) will be 
ignored for this statement The dumps specified by the 
data list are taken for the value of v, namely ai through 
as in increments of as, or increments of one if as is 
omitted. The maximum depth to which ranges may be 
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nested is three. The following *examplfe of element 
specification is invalid because it contains four nested 
ranges : 
{(((A(I, J, K), B(I, J, L), 1 = 1, 2), J = l, 2), K = l, 2), L=:l, 2) 

The following are valid examples of this element 
specification: 

(A(I, I), 1 = 1,3) 

dumps An, A-., Axi. 
(B(I, 6-1), 1=1,5,2) 

dumps Btn, Baa, B.-,i. 

((A(I,J),I= 1,3),J = 6,8,2) 

dumps Ain, Aafl, A.in, Aim, Ajh, Ash. 

((C(2*J-4, 10-3*1), 1 = 1,3), J = 3,4) 

dumps C27, Ca4, C21, €47, Cu, d, 
(A(J, J), (C(2*J-4, 10-3*1), 1 = 1, 3), J = 3, 4) 

dumps Ass, C27, C24, C21, A44, C47, Cu, d. 

The statement 
DUMP(A(I,J),I=1,4) 
dumps a(ij), a(2,j), a(3j), and a(4,j), where j is a 
variable previously defined either in the source pro- 
gram or in a name statement. 

4. // or /control section name/— This causes blank 
COMMON or the control section named to be dumped. 

// ±n or /control section name/ ±n— This causes 
the location at the beginning of blank common ± n or 
the location at the control section ± n to be dumped. 
FORTRAN labeled common names are control section 
names. 

5. PROGRAM— This causes the entire object program 
exclusive of library subroutines to be dumped. 

6. msg'— This causes the message to be printed as it 
appears. The symbol msg refers to any message not 
containing a quotation mark; however, the external 
quotation marks are required. 

7. CONSOLE — This causes the following items to be 
written: the contents of the accumulator, the multi- 
plier-quotient register, the sense indicators, the index 
registers, as well as the status of the sense lights, the 
sense switches, the entry keys, and the trapping, over- 
flow, divide check, and i-o check indicators. 

To allow for interdeck communication, any item or 
set of items may be qualified with an associated deck 
name by preceding it with the deck name and two con- 
necting dollar signs, as follows: 
deckname$$item 

or 
deckname$$ (item, item, ... .) 

For example, a$$b refers to symbol b in deck a and 
the statement dump ab$$(bb,cb,(rb,sb,o) ) dumps items 
BB, CB, and the octal region rb through sb in deck ab. 
NAME Stafmmnt 

The NAME statement permits the programmer to define 
symbols for use within debug requests and to supply 
modal and/or dimensional information for the symbols. 
This definition overrides any other definition or any 
other associated information for the symbol within de- 
bugging text. The form of the name statement used 
primarily by the Fortran programmer is: 



NAME symbol, / = NEW [ ( mode [ ( dimensions ) ] ) ] 
[,symbol../ = NE\V [( mode[( dimensions )] )] . . . ] 

where the parameters are defined as follows: 
I symbol Any valid FORTRAN symbol. 

= NEW =NEW specifies that a location of octal format 

or an area corresponding to the specified mode 
and dimensions is generated for the symbol. 
I ( mode) Mode can be either X, F, D, J, H, or L. These 

are defined in the section "The List Statement." 
( dimensions ) The dimensions are the same as the dimensions 
specified by a DIMENSION statement. (For an 
explanation of this statement and examples of it, 
sec the section entitled "DIMENSION State- 
ment" in the publication IBM 7090/7094 IBSYS 
Operating System: FORTRAN IV Language, 
Form C28-6390. ) 

This form of the name statement may be used to 
establish variables for use in the debugging requests 
beyond those defined in the debugging dictionaries. 
The name statement in the request must precede any 
references to the symbol it defines. No more than three 
dimensions may be specified. 

Debugging Dictionary 

The debugging dictionary is a communication device 
between the program that is being debugged and the 
debug package. This dictionary contains symbols and 
pertinent data about the symbols, such as their relative 
locations, their modes, and their dimensions. It also 
contains Fortran statement numbers and their relative 
locations. If requested by the programmer on a sibmap 
or a sibftc control card, the debugging dictionary is 
produced. Further information about the debugging 
dictionary is contained in the publication IBM 7090/ 
7094 IBSYS Operating System, IB J OB Processor, Form 
C28-6389. 

A fORTRAN IV Load-Time Debugging Packet 

Figure 2 is the program main, and Figure 3 is the sub- 
routine SUBR. 

OIHENSION IRRAVAm 
DC 25 I.l ,<. 

?5 CCNTINllf 

DC 26 1-1,1 

K^l 

CALL SI1RP{«RR«V»,K 1 
26 COMINIIF 

STCP 

ENC 

Figure 2. Program MAIN 

SU8RCUTINE SUBR(C,K) 

DIMENSION DO) 

Z«6 
I DO 30 1-1,9 

DIKI«K*I«10 
30 CONTINUE 

RETURN 

END 

' Figure 3. Subroutine SUBR in deck MIDDLE 

Figure 4 is an example of a Fortran iv load-time de- 
bugging packet. The sibdbl card heading the packet 
calls in the debugging compiler. Also, it specifies that 
all debugging activity is to cease when 450 debug re- 
quests have been executed at object time and that a 
maximum of 500 lines of debugging output is to be 
printed. 



Load-Time Debugging for FORTRAN IV and MAP Programs 1 1 



•OMuc MAIN 25*' ''•*"*'°' '■^''^ MAx-500 a^^j the tjj^fj request dumps the array, arraya, in pro- 

NAME A/-NEMIXI gram MAIN the third time that Statement 30 in MmoLE 

ON I SET A-13 ° 

IF L 6E A RETURN Is exeCUtcd. 

DUMP AtLt'L TOO SMALL* 

SET A-A-i Xhe ■•'DEND Card terminates the action of the debug- 

•OEBUe MIDDLE 1 ^ 

NAME x/-NEMixi - ging Compiler. 

SET X-l 

.OEBuc^MiooLE ^30^^ ^^^ „a,n»»arraya ^^g"^^ ^ is the output from the debugging postproc- 

•OENO essor that was obtained from the programs in Figures 

2, 3, and 4. 
Figure 4. Example of a FORTRAN IV Load-Time Debugging 
Packet 

Additional Load-Time Debugging Features 

The first debug request is executed at statement 25 ^he following sections contain descriptions of addi- 

in deck MAIN. The fixed-point variable A is defined for ^'^^^^ debugging facilities that are of interest mainly 

use in the debugging request for deck main. The first *» *e map programmer. They may also be used by the 

time that statement 25 is executed, A is set to 13. L (in forttian or eoBOL programmer. 

program main) is tested each time prior to the execu- ^ , , . ..... .. . ^ . 

. ^ «- Tr X . 1 , X * IT Quantitht Avallablm tor f/s« In Dmbug fteqvasf Stotmmmnt* 

tion of statement 25. If L is less than A, A and L are _, _ . , , , , , 

J J ,1 „ . „.,.•• • * J J A The quantities in Table i are available for use in the 

dumped, the message l too small is printed, and A ^ . , , r i , i 

.J Ji.iT£T--— i.^u i*.A statements that make up the text of the debug request. 

is decreased by I. If L is greater than or equal to A, ^ & ^ 

return is made to the interrupted program. Then, state- Numerical constants may be used in arithmetic ex- 
ment 25 is executed, (.dgbtx and .ibdb* on the dump pressions. A constant may be decimal floating point, 
refer to the debugging compiler output deck and the decimal integer, or octal integer. If a number n con- 
name of a control section used for definition of =new *a»ns » period, it is a floating point number; in this 
symbols respectively. ) ^^^^' ^" ^' *^' ^^ "*> f oWowed by an exponent may be 

Tu JJ1.UJJL . ..J I present, ee or d is used to indicate double precision 

The second and third debug requests are executed '„ . .xr,« , ,,f 

.^. ., joA *iji floating point. If the first character of n (other than 

at statements 1 and 30 respectively, m deck middle. . f , , 

o 1.U i J 1 II u + or — ) IS a zero and n does not contain a period, an 

Suppose that deck MAIN calls subprogram MroDLE sev- • i .. . i. , i 

1 \.- J xu .. . X . 1 . .1. r. . . i_i 6ign*' or a nine, n is an octal integer and may be up to 

eral times and that statement 1 is the first executable ^3 ^.^^^ .„ ^^^^^ Otherwise, n is a decimal integer, 

statement in middle. Further suppose that middle con- Complex constants are written in the form (m, n,), 

tains a do loop that causes statement 30 to be executed where n, is the real part and nj is the imaginary part, 

many Hmes. Under these conditions, the second request Although the machine representadon is floating point, 

sets the counter X to 1 each time that MroDLE is called, m and n2 can be octal, decimal, or floating point. 

1, ••«■•••. CUKP REQUEST *T 3«, RCL LOC 00022, ABS LOC 04023, tN DECK FAIN 

lA.A.X) 

.DtGTK A .IBDB4 

00224 0SS19 A +13. 

(L.LtX) 

MAIN L «43 

00093 0A054 L *12. 

L TOq SHALL 

2, >••••••■ CUMP RECUEST AT 4A, REL LOC 00056. ABS LOC 04137, IN DECK MIDDLE 

IARRAyA,ARRAVA«2.F) 

MAIN ARRAVA *39 (3) 

00047 04090 ARRAVA *.31CC0OOO«O2 -.18469318-18 -.18469318-18 

3, •■••«••• CUHP RECUEST AT 4A, REL LOC 00096. ABS LOC 04137, IN DECK MIDDLE 

(ARRAYA, ARRAVA«2, El 

NAIN ARRAVA «39 131 

00047 04090 ARRAVA 4.<91C0COOO«02 «. 32000000*02 -.18469318-18 

4~. >••••••• CtNP REQUEST AT 4A. REL LOC 00096. ABS LOC 04137. IN DECK MIDDLE 

(ARRAVA. ARRAVA«2,FI 

MAIN ARRAVA *3<t (31 

00047 04090 ARRAVA *.41CC000O*O2 «. 92000000*02 *.330COCOO*02 



> Figure 5. Example of the Output of the Debugging P(»tprocessor 
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Tabic I. Additional Quantities Available for Use in Statements 



yiAMI lY 



= AC 

= AC(i) 
= AC(i,-i.J 

= LAC 

= LAC''(i) 

= LAe(i,-i.; 

= M0 

= MQ(i) 

= MQ(i,-i.) 



I = 



SI 

SI(i) 
SI(i,-i,) 



= XRk 



Accunnilator (S, 1, 2, . . . , 35) 
Acenmulator bit i; -^ i ',■ 35; l)it = S - bit 
Accumulator bits ii through i-; 

^ ii ^ is ^ 35; bit = S - bit 
Logical accmiiulator ( P, 1 , 2, , . . , 35 ) 
Logical accumulator bit i; 

'£: i -:: 35; bit = P - l)it 
Logical accimuilator bits i, through ij; 

^ i, ^ i, ^ 35; bit = P - bit 
Multiplier-quotient register (S, 1, 2, . . . , 35) 
Multiplier-quotient register bit i; 

<: i ^ 35; bit = S - bit 
Multiplier-quotient bit ii through i,; 

g i, ?i i, -S 35; bit = S - bit 
Sense indicator register (0-35) 

Sense indicator register bit i; '^ i '^ 35 
Sense indicator bits ii through i-; 

n r:^ i, 5^ i, ^ 35: 
Index register k; 

1 < k ^ 7 



"Loiiical accumulator may not bt* altorrd in a SET statement. 

The following arc examples of numerical constants: 
0120 octal integer 

129 decimal integer 

0129 decimal integer 

0.129E3 floating point 

(0120, -129) complex, having true value 

(-1-80.0, -129.0) 

'ixamp\^% of fhe Logical IF Statement 

The following examples of the logical ik clanse make 

use of some of the quantities that refer to internal 

registers. 

IF (=SI(17) OR = SI (21)) 
IF (=SI (3-7) E0 021) 

I IF (=XR4-8E0 3* = XR2) 

Redefining Symbols 

The *REDEF card allows the user to change the names 
of symbols used in source decks to make them accept- 
able for use in debug requests. Included arc symbols 
containing parentheses and map symbols that would be 
interpreted as numbers (e.g., o.ie.i, 4.r)KF,2, n:!;!.D4, 1.2). 
The general form of the *redef card is : 

1 8 16-72 
I ♦REDEF deckname old,bASbnew, [,old...bASbnew, ] 

where deckname is the deck in which the symbol to be 
redefined appears; b represents one or more blanks; the 
oldi are the symbols to be redefined; and the newj are 
the new names of the symbols. 

The variable field ( columns 16-72 ) of a *FEnEF card 
may be extended over more than one card by using the 
*ETC card which is described in the section "Load-Time 
Debug Requests." 

*REDEF cards, redefining symbols, must precede any 
use of the symbol newi. 

General NAME Statement 

The form of the general name statement is: 
NAME symbol,/ j _i,^gYi; [ [(mode [(dimensions)] )] 



, symbol-/ I _ J,.,,y M ( modc[(ilimensious )])]... 

where the parameters arc defined as follows: 

svmbol 



location 



= NEW 



mode 

( dimensions 



Any valid MAP symbol not containing paren- 
theses. 
A location designation as follows: 

1. A nonsubscripted symbol (plus or minus an 
integer, it desired). 

2. =Rn, a relative location where n is an im- 
signed octal integer. 

3. =Au, an absolute location where n is an un- 
signed octal integer. 

— NEW specifies that a location of octal format 
or an area corresponding to the specified mode 
and dimensions is to be generated for the symbol. 
Identical to those given in the section "Supply- 
ing Modal Information to the Debugging Dic- 
tionary." For further evplanalio'i of dimensional 
information, see the section entitl(>d "Stor.iet 
Allocation Pseudo-oiieratinns" in the pnblirafion 
IBM 7(mh7()f)4 IHSYS Oprrdtiiic .S?/s7< m. \<;- 
sion 13: Matro As.scnihly rronram (MAPI L<in 
guafic Form C2H-6392. 

The general form of the name statement may be 

used not only to define symbols for use within debug 

requests but also to alI()\A' the us(^ of symbols within 

the source program where no dcbugiiing dictionary, or 

an insufficient one, has been supplied. In addition, this 

form of the xA>rK statemcMit supplies alternate^ modal 

and/or dimensional information to a symbol. 

KEEP Pseudo'Operation—For MAP Assemblies 

The KEEP pseudo-operation permits the programmer to 
specify a debugging dictionary that contains only those 
symbols he wishes to use in debug rcfjuv .sts. T..' for- 
mat of the KEEP pseud(>-operation is: 



NAME 
FIELD 



OPERATION 
FIFLD 



V Alt; Ml 1,1-: III i.n 



Blanks 



KEEP One or more symbols, 

separated by connn.is 



The symbols in the variable field are entered into the 
debugging dictionary along with any modal and di- 
mensional information that was supplied in iiss, nis. 
EQu, and svN pseudo-operations. Any number of keki" 
pseudo-operations may appear in a program. If the 
XODD option was specified on the sibmap card, the keep 
pseudo-operation is ignored. 

Qualified symbols may not be used in the variable 
field. If they occur, an error message is issued and the 
innermost name is used (e.g., asbsc, c is used). If the 
same name appears in several qualification sections, 
the first encountered in the deck is used. 

Trap Transfers to Subroutines Containing Debug Requests 

If a trap occurs during the execution of a debug re- 
quest, the routine to which control is thereby passed 
should not execute another debug request. Such a 
relationship between debug requests is called "nest- 
ing." An error message will result from the attempted 
execution of the second debug request and execution 
of the entire job will terminate. 
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Supplying Modal Information to iho Dobugging Dictionary 

iBFTC automatically produces a debugging dictionary 
containing modal and dimensional information. How- 
ever, the MAP programmer must supply this informa- 
tion himself in certain cases, i.e., when using bss, bes, 
EQU, and SYN. ( Only modal information may be given 
with a BES; dimensional data is ignored. ) This informa- 
tion is specified in additional subfields of the variable 
field of these operations, as follows: 



NAAIE 

FIELD 



OPERATION 
FIELD 



VARIABLE FIELD 



Symbols 




Value 

[, mode [(di, dj, dj)]] 



where symbol and value are the standard forms for 
these operations; mode is one of o, f, x, d, j, l, s, c, or 
H, as described in the discussion of the list statement; 
and d,, do, and da are the dimensions", if any, of the 
array denoted by the symbol. The following are exam- 
ples of these statements: 

A BSS 25.F(5,5) 

B EQU A+10, F(5,3.2) 

C SYN A+6,X 

AddroM Computation 

Address computation is a generalized form of indirect 
addressing. It is of special importance when complex 
tables or buffer chains must be manipulated. The nota- 
tion for address computation is: 

=C (base address, opl, op2, . . .) 
Address computation is essentially a set of chaining 
operations. Each operation acts on the result (called 
the effective address ) of the preceding operation. Any 
address ( e.g., a statement number, x, sym ( i + 3 ) , = Rio, 
= A703, but not x+3) can be used as a base address, 
and any machine register can be used as a base address 
if an extraction operation follows. The extraction opera- 
tions are (ii-ia), addr, and deck, where 0^ii^i2=35. 
The operation (ii-i2) extracts bits it through 12 of the 
word located at the address specified by the preceding 
operation; the bits thus extracted become the address 
used by the next operation. If io — i, + l>15, only the 
rightmost 15 bits are used, addr and decr are short 
forms of (21-35) and (3-17), respectively. Thus, 
= c(a,addr) denotes the address portion of a. 

The operation oompl complements the current effec- 
tive address to form the next effective address. 

The operators +, — , *, and /, have special meanings 
as shown in the following examples using the opera- 
tor + : 

+A means "add the address of A." 

+ A, +B means "add the address of A, 

then add the address of B." 

+ A + B means "add the value found by 

adding the contents of A to the 
contents of B." 



+n ' ■ ' (where n is an integer) means 

"add the value n." 
Thus, =c(a, + b) is the address of a plus the address 
iof b, while =c(a, + b+o) or =c(a, + =c(b)) is the 
address of a plus the contents of b. Subtraction, multi- 
plication, and division work similarly. 
The following are examples of address computation: 

= C ( A ) the address of A 

DUMP=C(A) same as DUMP A 

SET =C(A) = =C(B)+2 sameasSETA = B+2 
= C ( A, ADDR ) the address portion of the 

word at address A 

The statement 

DUMP =C( A, ADDR) 

dumps ( in octal ) the word whose location is specified 

in the address portion of the word at location a. 

Suppose that a contains 

PZE B, , 12 

then the statement 

DUMP (=C(A. ADDR), 

=C(A,ADDR, +=C(A,DECR), -1)) 

dumps b through b + 1 1 . 

The statement 

DUMP=C(A, +B) 
dumps the contents of the location computed by add- 
ing the address of a to the address of b. This is usually 
only meaningful if one of these addresses is absolute 
(i.e., not a relative value that is adjusted by the 
Loader). 
The statement 

DUMP=C(=A3, -=XR4) 
or the statement 

DUMP =C( =A77775, + =XR4, COMPL) 
dumps the contents of the word at three plus the com- 
plement of index register 4. 
The statement 

DUMP»C(3, -=XR4) 
dumps the contents of statement number 3 plus the 
complement of index register 4. 

Bit Extraction 

In arithmetic expressions (e.g., in set, if, call, and on 
statements and also in address computation and in sub- 
scripts), it is convenient to be able to handle partial 
word operations. The notation to be used is: 

= C ( address computation ) ( bit specification ) 

or 
= mr ( bit specification ) 

where the bit specification is U—U, addr, or deck, with 
0^ii^i2=35. mr denotes AC, lac^, mq, si, or XRk. The 
notation 

»mr(i) 
where 0^i^35 is also permitted. 

The following are examples of partial word opera- 
tions: 



Arrays are structured and referenced as In FORTRAN. 



7 The logical accumulator may not be altered in a SET statement. 
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= C ( A ) ( DECR ) the decrement portion of A 

= C(A)( 18-20) the tag of A 

= AC ( ) the sign of the ateuinnlator 

= SI( 17 ) l)it 17 of the sense indicators 

= C(= AC) (18-20) invahd 

The statement 

SET=CfA)(DECR) = =C(B)( 18-20) -1-6 
replaces the decrement of the word at a with the snm 
of 6 and the tag of b. 
The statement 

IF =SI(4-7) EQ012SET=AC(ADDR)=Q 
replaces the address portion of the accumulator with 
the address portion of the word q (the rest of the 
accumulator is not affected) if sense indicator bits 4 
and 6 are 1, and bits 5 and 7 are 0. 
The statement 

DUMP A(=C(B)(10-17)) 
dumps the j"' element of the array a, where j is the 
number found in bits 10 through 17 in the word at loca- 
tion B. 



A MAP Load-Time Debugging Packet 

The numbers across the top of the example in Figure 6 
indicate the card columns in which the various fields 
begin. 

The siBDBL card heading the packet specifies that all 
debugging activity is to cease when 1,000 requests have 
been executed and that a maximum of 500 lines of de- 
bugging output is to be printed. 

The first request is executed the first time and each 
time thereafter up to but not including the eleventh 
time that statement number 34 in decka is to be exe- 
cuted. This request specifies that the elements in list 
statement numbers 2 and 3 (which appear later in the 
packet) are to be dumped. 

The second request is executed prior to each execu- 
tion of statement number 42 in decka. It tests the value 
of a-b*c against 3.r,*D and returns to the interrupted 
program if they are not equal. If they are equal, it 
dumps the range (in complex number format) from 
U through V (if V is an array, the whole array will be 
dumped), darray,, 7, a, and the message a-b*c eq s.-'s+d 
caused program stop. Program execution then stops 
and the postprocessor is called. 

The second request also contains list statement 
number 3, which, when used in a dump statement, 
causes the following information to be dumped: 

alphas, ,, alphas, 2, ALPHAj,, ,, ALPHAn, L>, • . . , ALPHAu, 2; 

all of the elements of barray; and all of blank common. 
The third request is executed prior to each execution 
of the instruction at start + i7 in deckb. On the third, 
sixth, ninth, twelfth, fifteenth, and eighteenth times 
that variable logvar is true (i.e., nonzero) the follow- 
ing will be dumped: X; control section cntrla; the 



region from relative locations 6 through 103k, in octal 
format; and the elements in list statement number 4, 
which is contained in another debug request. 

The fourth request is executed on the hundredth time 
that statement number 34 in decka is to be executed. At 
all other times, it simply returns control to the inter- 
rupted program. The information dumped consists of 
the console registers and indicators (list statement 
number 2) and the elements specified in list statement 
number 3, which is contained in the second request. 

Referring to Figure 6, note that in the lines beginning 
***error approximately at V the V is an arrow point- 
ing to the approximate part of the source statement in 
which an error has occurred. 

The fourth request also contains list statement num- 
ber 4, which, when used in a dump statement, causes 
the principle diagonal of the matrix carray (in decka) 
to be dumped. 

The fifth request is executed the first time and every 
second time thereafter through the ninth time that the 
instruction at restrt in deckb is to be executed. It tests 
variable Q and, if Q is negative, dumps the elements 
in LIST statement number 2 ( which is contained in the 
fourth request); the message q less than O; and the 
elements in list statement number 6 which specifies 
the region from restrt through restrt + 100 in sym- 
bolic format. 

The sixth request is executed prior to each execution 
of statement numbers 37 and 42 in decka. If A is less 
than B, it simply returns control to the interrupted pro- 
gram; otherwise it dumps a, b, E], Eo, and e.-,. 



SIBOBL TRAP MAX"1000t LINE«500 

•DEBUG DECKA 3<» 

ON It 10 DUMP 2t3 
•DEBUG DECRA 42 

IF A-B»C NE 3.5»D RETURN 
DUMP (U.VtJ) .DARRAY(lt7.3), 
X 'A-B»C EO 3.5^D CAUSED PROGRAM STOP' 
STOP 
3 LIST ( (ALPHA( I.J>tJ«lt2l .l»8fll ) t 

X BARRAY.// 
♦ DEBUG DECKB START + 17 ' 

IF (LOGVAR) ON 3.18.3 DUMP X./CNTRLA/. 
X (-R6.-R103.O) .4 
•DEBUG DECKA 3* 

ON 100 GO TO 10 
RETURN 
10 DUMP 2.3 

DUMP 'DATA'.-AC.-XRI.hRKS) .■A117(0) 
•♦♦ ILLEGAL LIST ELEMENT. ELEMENT DELETED. 
••• ERROR APPROXIMATELY AT V 

AC.-XRlt-Rl(S)«-A117(0) 
•♦• ILLEGAL LIST ELEMENT. ELEMENT DELETED. 
••• ERROR APPROXIMATELY AT V 
R1<S).-AU7(0) 
STOP 
2 LIST CONSOLE 
h LIST (CARRAY( I.n.I>1.10) 

•DEBUG DECKB RESTRT 

ON 1.10.2 IF LT 0.0 DUMP 2. 
X '0 LESS THAN 0* .6 
6 LIST (RESTRT. RESTRT+lOO.S) 
♦DEBUG DECKA 37.42 

IF (A .LT. Bl RETURN 
DUMP A»B.(E( J) .J«1.3) 
♦ DENO 



Figure 6. Example of a MAP Load-Tinie Debugging Packet 
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lnd«x 

absolute location 7, 9 

I accumulator 12, 13 

ADDR 14 

address 

base 14 

effective 14 

address computation 14 

arithmetic exprtissions 9, 10, 12 

arithmetic operators 9 

arrays 9, 14 

base address 14 

BES pseudo-op«;ration 13 

bit extraction 14 

blanks 7.8 

blank COMMON 11 

BSS pseudo-operation 13 

buffer chains 14 

CALL statement 8 

$CBEND card 5 

I COBOL 2. 5 

COBOL compiler 5 

COBOL programmer 12 

comment cards 8 

COMMON 

blank 11 

labeled 11 

compile-time debugging 5 

compile-time debugging packet .... 5, 6 
compile-time debug request 5 

headed by 5 

terminated by 5 

text of 5 

I COMPL 14 

I console 11 

$-control card 5 

control section name 11 

count-conditional statement 5, 9 

general form 5 

purpose 5 

counter 9 

name 9 

data items 5 

data list 10 

•DEBUG card 7 

parameters 7 

text of 7 

debugging dictionary 9, II, 13 

modal information to 13 

option 7 

debugging language 7 

load-time 7 

debugging packet 5, 6, 7, 1 1, 15 

compile-time 5, 6 

load-time 7,11,15 

debug request 7, 12 

quantities available or use in . . 12 

text of 7 

decimal 7 

DECR 14 

I'DENDcard 7,12 

display statements 5 

I DUMP statement 8, 9 

absolute location 9 

format 9 

general form 9 

item 9 

I LIST statement , 8, 10 

mode 9 

post processor 9 

relative locatfon 9 

statement numbers 9 

. SYSCK2 9 

I SYSOUl 5, 9 

effective address 14 

element specification 10 

end-of-file card 5 

EQU pseudo-operation 13 

expressions 

arithmetic 8.9.12 



logical 8 

I 'ETC card 8,13 

extraction operation 14 

I FORTRAN IV language 2 

FORTRAN rv programmer 7, 12 

FORTRAN IV 11 

GO TO statement 8 

SIBDBC card 5 

general form 5 

purpose 5 

$1BDBL card 7,11 

$IBFTCcard 11 

SIBMAP card 11 

IF statement 8, 13 

general form 8 

I index registers 12, 13 

indirect addressing 14 

insertion point 7 

integer 7, 10 

octal 10 

interdeck communication 11 

internal formula number 7 

I internal registers 11, 12, 13 

items 9, 10 

KEEP pseudo-operation 13 

BES pseudo-operation 13 

BSS pseudo-operation 13 

EQU pseudo-operation 13 

format 13 

SYN pseudo-operation 13 

I keys 11 

labeled COMMON 11 

I LIST statement 8, 10 

absolute location 10 

I accumulator 12, 13 

addressing quantities 10 

arithmetic expressions 10 

array 10 

blank COMMON 11 

I CONSOLE 11 

control section name 10 

data list 10 

element specification 10 

I index registers 12, 13 

interdeck communication 11 

items 10 

I keys 11 

labeled COMMON 11 

I logical accumulator 12, 13 

mode of dump 10 

I multiplier-quotient register 12, 13 

object program 10 

octal integer 10 

PROGRAM 11 

quantity 10, 12 

range 10 

I register! 10,12,13 

relative location 10 

I sense indicators 12, 13 

subscripts 10 

symbol 10 

"symbol" 10 

I trapping and overflow indicators 1 1 

load-time debugging 7 

load-time debugging packet 7, 11, 15 

load-time facility 7 

location 7,9,10,11 

.-tbsolute 7,9,10 

relative 7,9,11 

I logical accumulator 12, 13 

logical IF statement 8, 13 

arithmetic operator 9 

general form 8 

hierarchy of operation 9 

internal registers 13 

logical expressions 8 

logical operations 8 

ON statement 9 



parentheses 9 

relational operator 8 

logical operators 8 

machine registers 8, 14 

I MAP 2,15 

object program 7 

MAP programmer 7, 12, 13 

MAP symbols 8,13 

messages 11 

mode 11, 13 

NAME statement 8, 11, 13 

absolute location 13 

debug request 11, 13 

debugging dictionary 11 

dimensional information 11 

dimensions 11 

form 11,13 

FORTRAN programmer 11 

I MAP programmer 13 

modal 11, 13 

mode 11, 13 

symbols 11, 13 

text 11 

nested debug requests 8, 13 

notation conventions 2 

numerical constants 12, 13 

octal 7,10 

characters 7 

integer 10 

I ON statement 5, 8, 9 

count-conditional statement 9 

counter 9 

counter name 9 

debugging dictionary 9 

general form 9 

operations 

extraction 14 

hierarchy of 9 

logical 8 

operators 

arithmetic 9 

logical 8 

relational 8 

overlay 8 

parentheses 9 

PAUSE statement 8 

postprocessor 9 

procedure name 5 

I PROGRAM 11 

quantities for use in debug request 

statements 12 

range 10 

•REDEFc^ard 7,8,13 

general form 13 

variable field of 13 

registers 9 

internal 13 

machine -8 

relational operators 8 

relative location 7, 9, 10, 11 

RETURN statement 8 

SET ( arithmetic ) statement 8 

exponentiation 8 

fimctions 8 

logical constants 8 

statement number 7, 8, 9 

STOP statement 8 

STR instruction 7 

subscripts 9 

symbols 7,9.10,11 

MAP 7.8,13 

redefining 13 

SYN pseudo-operation 13 

SYSCK2 9 

SYSOUl 5,9 

tables 14 

unconditional GO TO statement . . 8 
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